Wasm × 機械学習

ブラウザでLLM。

@reach_vb

Phi 3 running on your browser!

100% local, powered by WebGPU & Rust 🦀

https://scrapbox.io/files/663a3cbe4940c8002451e23a.png

WebGPU利用。

実際に試してみると分かるがLoad Modelする必要ある。2.5GBくらい。

今回の例も同様で、つまりブラウザという実行環境上でローカルLLM動かしました！みたいなデモになっているイメージ。

ローカルLLM on iOS の現状まとめのこの辺りの議論とも親しそう。

WebAssemblyでの機械学習モデルデプロイの動向

王道的な応用ですが、Google Meet の背景ぼかしは、ブラウザ上で Wasm としてデプロイしたモデルで行っています。

技術的にはMediaPipeを利用していて、TensorFlow Lite や C++で記述されたアルゴリズムを含む、ML パイプラインをまるごと Wasm に変換しブラウザで動かしています。 Wasm での SIMD 利用や、JavaScript と Wasm の行き来のオーバーヘッドを避ける設計とし、ネイティブレベルの速度を pure Wasm で実現しています。

https://qiita.com/yasudakn/items/f9f906bd21262d067a14

MediaPipeではWebAssemblyとして、C/C++, Rustなどで作ったブラウザ用のバイナリ(WASM)に変換して実行させることが可能で、この時点でJavaScriptよりもベースのパフォーマンスが向上することになります。更に肝心の推論処理について、Tensorflow Lite+XNNPACKをベースとしたCPUに対してSIMD(ベクトル)命令など使っているという点もパフォーマンスに大きく影響しているらしいです。

技術的には 2 アプローチ

ブラウザに実装された Wasm の機能だけ（pure Wasm）で頑張る

TensorFlow.js, TensorFlow Lite, MediaPipe など

BlazeFace のような超軽量モデルは十分

HW アクセラレーターやミドルウェアを使うため、Wasm からネイティブコードを呼び出す

各ライブラリで独自に設計（TVM, WASI-NN, ONNC-WASM）

ネイティブ呼び出しの界面をどこにするかで設計の違いがあっておもしろいですね

アプリケーション的には API は統一されていると嬉しいので、今後は WASI-NN に統一されていく？

LLMをWASM上で動かすについては以下の記事が分かりやすい。

WasmでLLMが動く仕組みの解説

このようにWASIの関数の実態はただのRuntime側の関数なので、実質なんでもできます。

wasi-nnはただの関数定義なので、これをRuntime側すなわち呼び出される側で「実装」して、呼び出せば良い。

で、WasmEdgeくん（Runtime）はwasi-nn実装を（ggmlとかであれば）既に終えているので、それを使うだけでモデルロードして...という形でLLM使えちゃうよってこと（WasmEdgeにGGMLすなわち実行環境ライブラリがポーティング？されている。ggml.cppという名前で。なのでGGMLなモデルを読み込んで実行できる）。

Wasmファイルからそればinference()とか呼び出すとWasmEdge側で作られた関数が呼び出され、こいつは裏側でggml再実装しているのでモデルを実行できる。

逆にいうとWasm Runtime側が対応してくれないとこのような形でWasmでLLMを実行はできない。